Mobile computing devices, such as mobile or wireless stations, cellphones, radios, laptops, wireless communication devices and the like, operate with a power storage device with a limited energy supply, such as a battery, fuel cell or the like. A mobile computing device needs a power source and, in many cases, this power source is a battery. For instance, cellular phones use various types of batteries to operate. The amount of time a mobile station can typically operate before the energy of the battery is consumed (which is often referred to as “battery life”), is often an important criteria that consumers use in choosing one brand or type of mobile computing device over another brand. The terms battery, energy storage device and power storage device are used interchangeably herein.
While the power storage device is generally rechargeable, it may not be convenient or even possible for a user to recharge. Accordingly, there is a need to maximize the useful operational time of a wireless computing device.
Additionally, different operating environments can cause the user to be surprised and/or frustrated when the battery runs out much more quickly than would typically be expected by the user. Thus, a variation or unexpected short battery life is very undesirable from a user perspective.
This is a particularly relevant problem for mobile computing devices running applications supported by an applications server because of the power drain due to the wireless data exchange between the mobile device and the server, since each upload or download causes the consumption of energy in the mobile device and server. The problem is especially acute in the mobile device, which is typically battery powered and has finite energy available. For example, a mobile device may employ an email server for uploading and downloading email in support of an email application, a contact server for uploading and downloading contact status in support of a social networking application, an information server for downloading movies, news, music, etc. in support of a media playing application, and a back-up/storage server for uploading mobile device data in support of a data back-up application. Typically, the mobile device and application server synchronize on a regular or periodic basis, i.e. they communicate, upload, download or exchange information at essentially regular or fixed time intervals, and in this document, the exchange of data between and mobile device running an application and an application server is referred to as “synchronization”, and the amount of time between data exchanges is referred to as the “synchronization interval” or “sync interval”, for a given application and application server. Thus, there is a need for increasing a length of a synchronization interval, in order to conserve energy in a power storage device of a wireless computing device, such as a mobile station, in order to prolong useful power storage device or battery life.
Generally, there is a tradeoff between good application performance which requires more frequent data exchanges, i.e. a short synchronization interval, and good battery life which requires less frequent data exchanges, i.e. a long synchronization interval. For example, performance of an email application may be determined by the amount of time it takes to receive an email, and performance of a social networking application may be determined by the delay in receiving a change in a social contact's status.
The exchange of data with an application server may be initiated by the server, i.e. a “push” data service, or by the mobile, i.e. a “pull” data service. In the case of a “pull” data service the mobile device typically provides a timer operable to trigger the expiration of the synchronization interval at which time the mobile device may pole the application for the availability of new application data. Thus with a “pull” data service the mobile device is in control of the synchronization interval, also known as the pulling or poling interval. Conversely, in the case of a “push” data service the mobile device responds to the synchronization requests from the server which may or may not be periodic.
It is known to vary the synchronization interval according to the application, since the performance of certain applications may be more sensitive to synchronization frequency than others. It is also known that the requirement for timely synchronization varies with the state of the application. Synchronization may also be initiated a-periodically by the application running on the mobile device, or by the user. Thus, when multiple applications are running, each application is likely to require different synchronization intervals, which may or may not be controlled by the mobile device.
Synchronization of an application with an application server involves the uploading or downloading of application data between the mobile device and the application server over the communication infrastructure. Before the application data is exchanged with the application server there is a need to execute certain starting activities, such as powering-up the communication circuits, and establishment of a data communications session with the communication infrastructure. Similarly after the data is exchanged with the application server there is a need to execute certain ending activities, such as terminating the data communication session with the communication infrastructure and powering-down the data communication circuits. These starting and ending activities cause power drain in the mobile device. Thus there is a tendency for uncoordinated synchronization which causes power drain due to the stopping and starting activities associated with each data exchange. Thus, there is a need to minimize the starting and stopping activities by coordinating the synchronization times for multiple applications.
When operating a mobile device in synchronous communication with an application server, there is a tradeoff between good application performance which requires more frequent data exchanges, i.e. a short synchronization interval, and good battery life which requires less frequent data exchanges, i.e. a long synchronization interval
It is known to vary the synchronization interval according to a schedule, such that the period between downloading increases when certain applications are less likely to require frequent downloads. However, since application usage is a human behavior, the optimum download period cannot always be predicted and scheduled. Furthermore, the power drain due to the wireless data exchange with the application server may be unpredictable. The available wireless networks may be such that only data transmission methods requiring high power consumption are available. Hence, the optimum synchronization interval cannot always be predicted and scheduled. Thus, there is a need to provide a longer downloading synchronization interval or period for drawing less energy consumption at certain “dormant times”, while also providing shorter downloading synchronization intervals at “active times”, when an application requires timely information.
Also, there is a need to provide a longer downloading synchronization interval or period for drawing less energy consumption when the energy required for synchronization is higher, while also providing shorter downloading synchronization interval when the energy required for synchronization is lower, thereby taking advantage of favorable network conditions which may be temporary.
In connection with push applications, data is pushed on a regular interval from an application server, and Applicant is not aware of a method available at any mobile client for adjusting the pushing interval. It would be considered an improvement in the art, if a mobile device could autonomously adjust the rate at which it accepts pushed data. In addition, it would also be considered an improvement in the art if a mobile device could control applications in which data is pushed from an application server to the mobile device.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve the understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.